Method and communication system for processing alarms using a management network involving several layers of management

ABSTRACT

The invention is based on the alarm data for active alarms being transmitted for alarm realignment between an agent (AG) on one management level (B, C) and at least one manager (MA 1 , MA 2 ) on a next highest management level (A, B). Furthermore, the manager (MA 1 , MA 2 ) sends one or more request notifications (repAA) to the agent (AG) for transmission of the alarm data, and receives correlation information (alaAH, aliNI) for assigning the respective request to the notifications (alNO) subsequently sent by the agent (AG). According to the invention, the manager (MA 1 , MA 2 ) controls the alarm realignment on the basis of at least one parameter sent to the agent. The subject of the invention makes alarm realignment parameterizable for the manager, as regards the basic set of functions—use of the correlation information—, i.e. it is no longer necessary for all active alarms to be imperatively sent by the agent, but only those defined in more detail by the transmitted parameters. The result of this is optimum use of the transmission resources on the interface of the agent/manager relationship and the fastest possible provision by the agent of only that alarm data which is desired by the manager.

The invention relates to a method and to a corresponding communicationsystem for handling alarms using a management network which has aplurality of management levels, the alarm data for active alarms beingtransmitted for alarm realignment between an agent on one managementlevel and at least one manager on a next highest management level.

The principles of a management network, which are also called TMN(Telecommunications Management Network) principles, define a pluralityof management levels for managing a communication system—for example amobile communication system—, each level having a dual function. In themanaging system, every level except for the bottom one has a managerfunction for the level situated below it. In the managed system, everylevel except for the top one has an agent function for the next highestlevel.

Fault management is an important part of TMN management. In principle,the agent plays the active role here by recognizing, in good time andaccurately, faults on its own management level and transmitting them asalarms to the manager on the next highest level. The transmission ofalarm data from the agent to the manager is not critical as long as thecommunication mechanism between these systems is not impaired. If theconnection between the two management levels, that is to say between theagent and the manager, is no longer ensured for a particular time, theagent must temporarily store the alarms which have occurred during thisinterval to ensure that, after the possibility of communication has beenrestored, an overview of the currently active alarms—e.g. in the form ofa list—is provided to the manager as quickly as possible, on the onehand, and, on the other hand, the manager can establish as complete analarm history as possible both for the active and for the clearedalarms.

For this purpose, alarm realignment between the agent and the manager iscarried out whenever a new connection is established after a connectionhas been terminated or after the agent or the manager has beeninitialized. All the alarm data for active alarms for which faults havenot yet been cleared in the agent—which can be recognized from the factthat they are not identified as “cleared alarms”—can therefore beprovided to the next highest management level in full and as quickly aspossible.

The earlier patent application P 19752614.4 specifies such a method andcommunication system for handling alarms describing a basic set offunctions for the manager to request all the alarms from the agent. Inthis context, the agent sends the active alarms as a sequence ofstandardized M-EVENT-REPORTS which is embedded in an M-ACTION requestinitiated by the manager at the start and in an M-ACTION responseinitiated by the agent at the end. These are generic CMISE-standardized(Common Management Information Service Element) procedures defined onthe basis of ITU-T X.710. ITU-T X.733 defines the content of astandardized alarm transmission (alarm report) implemented on the basisof the M-EVENT-REPORT services. All M-EVENT-REPORTS defined under thisM-ACTION are explicitly correlated to the respective request usingcorrelation information. This allows the manager to assign theseM-EVENT-REPORTS to a particular request, and, furthermore, todistinguish them from other, “regular” M-EVENT-REPORTS.

The object of the invention is to specify such a method andcommunication system for handling alarms using a management networkwhich has a plurality of management levels and optimizes alarmrealignment between an agent and at least one manager.

The invention achieves this object, in terms of the method, with thefeatures of patent claim 1, and, in terms of the communication system,with the features of patent claim 12. Developments of the invention canbe found in the subclaims.

The invention is based on the alarm data for active alarms beingtransmitted for alarm realignment between an agent on one managementlevel and at least one manager on a next highest management level.Furthermore, the manager sends one or more request notifications to theagent for transmission of the alarm data, and receives correlationinformation for assigning the respective request to the notificationswith the alarm data which are subsequently sent by the agent. Accordingto the invention, the manager controls the alarm realignment on thebasis of at least one parameter sent to the agent.

The subject of the invention makes alarm realignment parameterizable forthe manager, as regards the basic set of functions, i.e. it is no longernecessary for all active alarms to be imperatively sent by the agent,but only those defined in more detail by the transmitted parameters.This provides the manager with a selection function for a subset fromall the alarms. The possibility, in particular, of controllingrealignment using simple means and using standardized notificationsincreases the manager's flexibility and significantly reduces the flowof notifications and information. For the first time, theparameterizable alignment functions according to the invention make itpossible, by way of example, to prioritize the alarms and/or to haveactive control over the sequence of the requested alarms. Particularlythe combination of the basic set of functions—use of the correlationinformation—with the parameterizable alignment functions produces aparticularly effective method and communication system, resulting inoptimum use of the transmission resources on the interface of theagent/manager relationship and the fastest possible provision by theagent of only that alarm data for active alarms for the next highestmanagement level which is desired by the manager.

According to one development of the invention, the manager sends theparameter or parameters to the agent in each request notification. Thismeans that the manager's desired parameterization of alarm realignmenttakes place individually for every single request.

According to one alternative development of the invention, the managersends the parameter or parameters to the agent in a setting notificationwhich has precedence over the request notifications. This means that themanager's desired parameterization of alarm realignment takes place,before the first request notification, jointly for a plurality ofrequests for which the manager's one-off setting contained in thesetting notification is valid.

According to further advantageous developments of the invention,parameterization can take place with one or more of the followingparameter values set by the manager in each case. The parameter valuerequests, from the agent, alarms

which originate from selected agent units,

for which there is an assumed urgency,

which the agent uses during sending to prioritize the requested alarmsaccording to their urgency, preferably using different urgency values,

which originate within a time interval defined by a start instant and anend instant,

which the agent uses during sending to prioritize the alarms accordingto the origination instant of the alarms.

In one refinement of the subject of the invention, the agent providesand sends the alarm data for the alarms having the earliest originationinstants first, and provides and sends the alarm data for the alarmshaving the most recent origination instants last.

Thus, in a particularly beneficial refinement of the subject of theinvention, the agent provides and sends the alarm data for alarms havingcritical urgency, for which the set of functions is assumed to be nolonger present, first, and provides and sends the alarm data for alarmshaving noncritical urgency, for which the set of functions is assumed tobe still present, last.

Using the above procedure, the manager can deliberately call up thosealarms which are particularly critical in terms of functions, and henceare important to said manager, and can thus significantly reduce theload on the interface with the agent, as compared with the conventionalmethod for automatically reporting all alarms, as a result of the flowof information limited only to particular alarms.

The invention is explained in more detail below using illustrativeembodiments with reference to the figures, in which

FIG. 1 shows the block diagram of a management network for a mobilecommunication system with an agent/manager relationship between anoperation and maintenance center and one or more network managementcenters,

FIG. 2 shows the block diagram of the management network shown in FIG. 1with an agent/manager relationship between a base station subsystem andan operation and maintenance center for implementing at least twoapplications for the base station subsystem,

FIG. 3 shows the block diagram of the agent and the manager for handlingthe alarms for alarm realignments taking place in parallel or serially,

FIG. 4 shows the notification flow between the manager and the agent forthe individual parameter-dependent control of alarm realignment in eachrequest notification,

FIG. 5 shows the notification flow in accordance with FIG. 4, based onthe example of the use of two different parameter values,

FIG. 6 shows the notification flow between the manager and the agent forthe parameter-dependent control of alarm realignment using a one-offsetting for a plurality of request notifications,

FIG. 7 shows the notification flow in accordance with FIG. 6, based onthe example of the use of two different parameter values, and

FIG. 8 shows the notification flow between the manager and the agent forpolling the parameter values used for the alarm realignment, as shown inFIG. 7.

The illustrative embodiment describes the invention using a TMN conceptfor the management of a mobile communication system which, by way ofexample, has network elements in a mobile radio network based on the GSMstandard. However, the invention is not restricted to mobile radionetworks, but can be applied to any kind of telecommunication networkswhich use a TMN management network.

A mobile communication system is a hierarchically structured system ofdifferent network elements, in which the bottom stage of the hierarchyis formed by the mobile stations. These mobile stations communicate, viaa radio interface, with radio stations which form the next level of thehierarchy and are called base stations. The base stations, which supply,by way of example, mobile stations in a radio range of a radio cell, arepreferably combined to cover a relatively large radio area and areconnected to superordinate network elements, the base stationcontrollers. The base stations and base station controllers are part ofa base station subsystem of the mobile communication system. The basestation controllers communicate, via defined interfaces, with one ormore switching centers, the mobile exchanges, which are also used, amongother things, for crossing to other communication networks. The mobileexchanges form, together with a plurality of databases, the switchingsubsystem of the mobile communication system.

In addition to the above network elements, there are one or moreoperation and maintenance centers, which, among other things, are usedto configure and monitor the network elements. In this regard,monitoring measures and configuration measures are usually controlledremotely from operation and maintenance centers, which are normallyarranged in the region of the mobile exchanges. An operation andmaintenance center in this case communicates with a respective basestation subsystem or switching subsystem via a defined interface. Afurther task of the operation and maintenance system is carrying outconfiguration management, which, in addition to fault management,represents one of five management function areas identified by the TMNprinciples. Configuration management defines a series of services whichenable the user to change the structure and hence the behavior of atelecommunication network. These services always relate to instances ofmanaged objects, which by and large form the network-specific managementinformation base.

A managed object, in the configuration management sense, is a logicalabstraction of a resource in the mobile communication system. In thiscase, a distinction is made between hardware-related managed objects,which describe manufacturer-specific realization of a function, andfunction-related managed objects, which each involve the abstraction ofa set of functions which is independent of the manufacturer.

For managing the mobile communication system, the TMN principles definea plurality of levels, three of these levels being explained below inthe present example with reference to FIGS. 1 and 2.

FIGS. 1 and 2 each show three levels A, B and C in the managementnetwork, of which management level C contains the network element levelhaving a plurality of base station subsystems BSS11, BSS12 . . . BSS1Nand BSS21, BSS22 . . . BSS2M. Management level B identifies the networkelement management level in which operation and maintenance centers OMC1and OMC2 each provide the manufacturer-specific management functions forindividual subsystems, such as the operation and maintenance center OMC1for the base station subsystems BSS11, BSS12 . . . BSS1N and theoperation and maintenance center OMC2 for the base station subsystemsBSS21, BSS22 . . . BSS2M in the present example. Management level Aidentifies the network management level in which network managementcenters NMC1 and NMC2 perform respective integrated management functionsthat are independent of the manufacturer. In this case, a plurality ofnetwork management centers can have access to the same network elementon the next lowest management level B, in the present example thenetwork management centers NMC1 and NMC2 on the next highest managementlevel A can have access to the operation and maintenance center OMC1 onthe next lowest management level B. Defined interfaces for transferringinformation are provided between the network elements on differentmanagement levels.

The difference between the illustrations shown in FIGS. 1 and 2 is thatan agent/manager relationship for handling alarms exists, for one ormore alarm realignments, in FIG. 1, between the operation andmaintenance center OMC1 (agent) and a network management center NMC1(manager) or a plurality of—physically separate—network managementcenters NMC1, NMC2 (managers), and in FIG. 2, between the base stationsubsystem BSS11 (agent) and two different applications OF1 and OF2(managers) in the operation and maintenance center OMC1 or between theoperation and maintenance center OMC1 (agent) and two differentapplications NF1 and NF2 (managers) in the network management centerNMC1. To ensure an overview of the fault situation in the networkmanagement centers NMC1, NMC2 at all times, the operation andmaintenance center OMC1—on the basis of faults occurring within thesupervised base station subsystems BSS11 . . . BSS1N, forexample—provides stored alarm data for active alarms and sends it toboth managers in parallel on request. This preferably occurs after aconnection has been terminated or after the agent or the manager hasbeen initialized. Similarly, a plurality of requests can also beaddressed to the agent, e.g. the operation and maintenance center OMC1,in succession by an individual manager, e.g. the network managementcenter NMC1. FIG. 1 shows the structure for alarm realignment requestswhich, in accordance with the invention, are transmitted a plurality oftimes and, in the present example, take place in parallel between themanagement level B, which contains the agent in the form of theoperation and maintenance center OMC1, and the next highest managementlevel A, in which the managers are formed by at least two networkmanagement centers NMC1, NMC2.

To ensure an overview of the fault situation at all times in managementlevel B as well, e.g. in the operation and maintenance center OMC1, thebase station subsystem BSS11—on the basis of faults occurring within thesupervised base stations and base station controllers, forexample—provides the stored alarm data for active alarms and sends it,in parallel, to at least two managers in the operation and maintenancecenter OMC1 in the form of the different applications OF1 and OF2, whichare both implemented by one and the same physical element OMC1. Thislikewise occurs preferably after a connection has been terminated orafter the agent or the manager has been initialized. Requests initiateda plurality of times by an individual manager, e.g. the operation andmaintenance center OMC1, can also be transmitted serially to the agent,e.g. the base station subsystem BSS11. As an alternative or in addition,an agent/manager relationship can also exist between the operation andmaintenance center OMC1 (an agent) and the network management centerNMC1 (a manager) for serial interchange of requests and alarm data orfor parallel interchange of requests and alarm data for at least twodifferent applications NF1 and NF2 (two managers) in the networkmanagement center NMC1. FIG. 2 shows the structure for alarmrealignments, taking place in parallel according to the invention,between management level B, which contains the managers in the form ofapplications OF1 and OF2, and the next lowest management level C, whichcontains the agent.

As soon as an internal interface which has failed on management level Cis operational again, the alarm realignment, also called realignmentprocedure or realignment method, is started at the request of themanager/managers, the manager controlling the alarm realignment on thebasis of parameters, in accordance with the invention. For this, in thepresent example, the alarm realignment is first started between the basestation subsystem, e.g. BSS11, and the applications OF1, OF2 in theoperation and maintenance center OMC1, in parallel, and is thencontinued between the operation and maintenance center OMC1 and thesuperordinate network management centers NMC1, NMC2 in parallel. At theend of these procedures, the fault situation both in the OMC and also inthe NMC is updated again. The realignment method can, of course, berestricted to updating the alarm data between the agent and the managerson two immediately adjacent management levels, e.g. level B and level A.

FIG. 3 shows a schematic illustration of the structure of the agent AGand the managers MA1, MA2 with the elements necessary for carrying outrealignment procedures performed simultaneously—in the case of two ormore managers—or serially—in the case of only one manager. Each managerMA1, MA2 and agent AG has a control element M-CTR and A-CTR,respectively, which can generate and evaluate the notifications for thealarm realignment. They also have transmission/reception elements (notshown in more detail) for transmitting and receiving the notifications,and memory elements for storing the alarm data and other usefulinformation and signaling information.

In this arrangement, the control elements M-CTR in the managers MA1, MA2insert an item of correlation information, which is used for assigningthe request to subsequently sent notifications, into the respectiverequest notification for transmission of the alarm data by the agent,said item of correlation information being explicit and promptingtransmission to the agent. Furthermore, the elements M-CTR in themanagers MA1, MA2 insert, for controlling the alarm realignment, one ormore parameters par into each request notification individually or intoa setting notification which has precedence over the requestnotifications, in order to make a deliberate request for particularalarms identified by various parameter values. The respective requestnotification or the separate setting notification is sent with theparameters par to the agent AG. For the first time, the parameterizablealignment functions according to the invention make it possible, by wayof example, to prioritize the alarms and/or to have active control overthe sequence of the requested alarms.

The control element A-CTR in the agent AG receives the correspondingnotification with the parameters par, evaluates it and startsrealignment in respect of the managers MA1, MA2 by sending back thealarms specifically requested by the managers. In this case, theexplicit item of correlation information entered in the requestnotification by the managers MA1, MA2 is used for correlating therequests, and a respective notification with a further item ofcorrelation information for assigning the notifications (alarmnotifications) subsequently sent by the agent for the respectivelystarted realignment is sent to the next highest management level. Thefurther item of correlation information is also explicit. The use of thecorrelation information allows realignments carried out simultaneouslyor serially to be explicitly assigned to a plurality of managers or toan individual manager.

Particularly the combination of the basic set of functions—use of thecorrelation information—with the parameterizable alignment functionsproduces a particularly effective method and communication system,resulting in optimum use of the transmission resources on the interfaceof the agent/manager relationship and the fastest possible provision bythe agent of only that alarm data for active alarms for the next highestmanagement level which is desired by the manager. Resource utilization,duration and flexibility are consequently optimized further, as comparedwith the basic set of functions, in the communication system designed inaccordance with the invention.

As an option, a plurality of filter functions EFD1, EFD2 (EventForwarding Discriminators), which can each be assigned to the managersMA1, MA2 and can be controlled by them, with filter criteria for thenotifications produced by the agent AG can also be used in the agent AG,so that the notifications with the alarm data are routed to the managersMA1, MA2 only if the filter criteria are satisfied. The manager'scontrol element M-CTR is able to set up and delete such filter functionsin the agent AG and to define the filter criteria in order to be able tocontrol the notification flow on the basis of its individualrequirements. The case can therefore arise in which the filter functionsetting differs from manager to manager, so that the simultaneouslyperformed realignment procedures handle alarms with different contentsusing associated alarm data.

FIG. 4 shows the notification flow between an agent AG—the operation andmaintenance center OMC1 in the example shown in FIG. 1 or the basestation subsystem BSS11 in the example shown in FIG. 2—and the managerMA1, MA2—the various network management centers NMC1, NMC2 in theexample shown in FIG. 1 or the various applications OF1, OF2 in theexample shown in FIG. 2.

The notification flow occurs preferably using standardizedM-EVENT-REPORT notifications embedded in an M-ACTION request initiatedat the start and in an M-ACTION response initiated at the end. These aregeneric CMISE-standardized (Common Management Information ServiceElement) procedures defined on the basis of ITU-T X.710. ITU-T X.733defines the content of a standardized alarm transmission (alarm report)implemented on the basis of the M-EVENT-REPORT services. The correlationinformation is entered in the notifications or in particularnotification fields. Furthermore, the managers MA1, MA2 provide theparameters for controlling the alarm realignment with particularparameter values and enter them in the respective request notificationindividually or in multiples. The example in FIG. 4 shows thenotification flow using individual notifications only, where these canbe transmitted in parallel between the agent AG and the managers MA1,MA2 or serially between the agent AG and the individual manager MA1.

As soon as communication is restored between the manager MA1, MA2 andthe agent AG after the connection is interrupted, each manager MA1, MA2sends the M-ACTION request with a request notification repAA (reportActive Alarms) for transmission of the alarm data. Preferably, an itemof correlation information alaAH (alarm Alignment Handle)—in the definednotification field “actionInformation”, for example—defined by themanager MA1, MA2 is sent as well, this item of correlation informationidentifying direct assignment of the current M-ACTION request to allsubsequent agent notifications. Consequently, with a plurality ofmanagers, the current request can also be assigned to the relevantmanager, so that the managers' parallel realignments can be initiated,carried out and ended independently of one another.

The request notification repAA also contains the parameter valuesentered by the manager for the subsequent functional sequence. This isused to request a one-off individual function execution (action) forparameter-dependent transmission of alarms by the agent AG.Parameterization can preferably take place with one or more setparameter values relEN (related Entities), relPS (related perceivedSeverity), priSV (prio severity), relTI (related Time Interval), priDT(prio Detection Time). The specific parameter value requests, from theagent, alarms

which originate from selected agent units (relEN),

for which there is an assumed urgency (relPS),

which the agent uses during sending to prioritize the requested alarmsaccording to their urgency, preferably using different urgency values(priSV),

which originate within a time interval defined by a start instant and anend instant (relTI),

which the agent uses during sending to prioritize the alarms accordingto the origination instant of the alarms (priDT).

The parameter values relEN . . . are contained in a notification field,stipulated according to the standard, of the M-ACTION request, so thatfields which already exist and are defined can also be used. Abeneficial variant involving time is where the agent provides and sendsthe alarm data for the alarms having the earliest origination instantsfirst, and provides and sends the alarm data for the alarms having themost recent origination instants last. A particularly suitable variantof the combination of parameter values relating to time and urgency iswhere the agent provides and sends the alarm data for alarms havingcritical urgency, for which the set of functions is assumed to be nolonger present, first, and provides and sends the alarm data for thealarms having noncritical urgency, for which the set of functions isassumed to be still present, last.

Following evaluation of the parameters in the M-ACTION request receivedand provision of only that alarm data which is associated with thealarms defined by the manager in the parameterized request, the agent AGstarts alarm realignment by producing a notification staAA (start AlarmAlignment) and inserting a further item of correlation information aliNI(alignment Notification Id) into this notification. The item ofcorrelation information aliNI entered by the agent AG allows subsequentalarms to be directly correlated to the respectively started alarmrealignment. For this, the item of correlation information alaAH islikewise contained in a particular notification field. The item ofcorrelation information aliNI is, by way of example, entered in thestandardized notification field “notification Identifier” in thenotification staAA. The two items of information alaAH, aliNI aretransmitted together in the notification staAA by the agent AG to themanagers MA1, MA2. This allows “alignment-related” M-EVENT-REPORTnotifications for different M-ACTION requests to be distinguished fromone another, and also from regular M-EVENT-REPORT notifications whichhave nothing to do with realignment. The reason for this is that analignment procedure does not necessarily stop other M-EVENT-REPORTnotifications which spontaneously arise during the alignment procedureand are sent to the manager(s).

The item of correlation information alaAH sent together with the requestnotification repAA for the M-ACTION request can be used to correlate thesubsequent notifications staAA and repAA directly, because they likewisecontain the item of correlation information alaAH. The notificationsalNO are directly correlated to the notification staAA by means of theitem of correlation information aliNI. The manager can correlate therequest notification repAA to the subsequent notifications alNOindirectly using the two items of correlation information alaAH andaliNI contained in the notification staAA.

Following the start of the alarm realignment, the alarms aresuccessively transmitted with the associated alarm data in successivenotifications alNO (alarm notification) using the M-EVENT-REPORTservice. In this context, the individual notifications alNO each havethe item of correlation information aliNI—in the defined notificationfield “correlated Notifications”, for example. After the lastM-EVENT-REPORT notification for the alarm realignment, the agent AGgenerates the M-ACTION response for the notification repAA (reportActive Alarms), which contains the item of correlation information alaAHfor explicitly identifying the respective request from the manager MA1,MA2. By evaluating this item of correlation information, each managerMA1, MA2 can easily recognize the end of its initiated M-ACTION requestand can assign the incoming alarm data to the requests. For the case inwhich no active alarms are stored at the instant of the M-ACTIONrequest, the agent initiates the M-ACTION response immediately after thenotification staAA is sent. The items of correlation information alaAH,aliNI for explicitly assigning a plurality of requests—for possiblesimultaneous realignments, to a plurality of managers, or for serialrealignments, to an individual manager—are nevertheless generated by theelements involved in the agent/manager relationship and are sent in thenotifications repAA, staAA. Even if the example described in relation toFIG. 4 relates to parallel realignments for a plurality of managers, thenotification flow can, of course, be applied to a plurality of requeststriggered in succession by an individual manager, with the advantagethat the explicit assignment using the correlation information providesthe individual manager with the option of being able to assign theincoming responses from the agent with the alarm data explicitly to therequests—for example from different applications in the manager—even ifthe sequence is not observed. Requests sent in succession can possiblyovertake one another, for example if a packet network is traversedbetween the agent and the manager.

FIG. 5 shows the notification flow shown in FIG. 4 when two differentparameter values are used, which in the present example are formed bythe parameter values priSV and relTI. The parameter value priSV assumesthe value TRUE, which signals to the agent that, for the alarms' sendingsequence, it should prioritize according to different urgency values. Ifthe parameter value priSV assumes another value (e.g. FALSE), the agentdispenses with prioritization according to urgency values. If theoptionally present field is not used at all by the manager forcontrolling the requested alarms, all the active alarms having anassumed urgency are transmitted (default mode). The second parametervalue relTI contains a sequence of two values inst (Interval Start) andinen (Interval End), which mark a start instant and an end instant fordefining a time interval. This means that only those alarms arerequested from the agent which originate within the time intervalidentified by inst, inen. If the optionally present field is not used atall by the manager for controlling the requested alarms, all the activealarms are transmitted without taking into account the originationinstant (default mode). In the present example, specifically only thealarms—prioritized according to their urgency (see commentsabove)—arising between “inst=12.01.98 10:15:00” and “inen=12.01.9811:15:00” are provided by the agent and sent to the manager.

On the basis of the example in FIG. 5, the alarm data for the selectedalarms is sent, using the M-EVENT-REPORT service, in the notificationsalNO, which follow the notification staAA. The individual notificationsalNO have, in addition to the correlation information aliNI, a value forthe urgency SV (perceived Severity) of the alarm and an originationinstant evT (event Time) for the alarm. The different urgency valuesrange from “critical” cri through “major” maj, “minor” min up to“noncritical” war (warning). A critical alarm is interpreted as beingone in which the set of functions is assumed to be no longer present,whereas, with a noncritical alarm, the set of functions is assumed to bestill present. If the manager receives the urgency value war, itinterprets this alarm as a warning relating to possible impairment ofthe agent's functions.

The set parameters relating to the urgency and relating to the timeinterval to be checked by the agent give the two notifications alNO,sent first, the values SV=cri, for the presence of critical urgency,with associated values evT=10:50:30 and evT=10:20:20 for the instants oftheir occurrence. The two immediately ensuing notifications alNO containthe values SV=maj, evT=10:25:50, for identifying an alarm having majorurgency, and the values SV=min, evT=10:22:10, for identifying an alarmhaving minor urgency. The notification alNO, sent last in the example,comprises the values SV=war, evT=10:17:30, equivalent to the display ofa warning to the manager. The notification sequence is suitable forindividually requesting particular alarms by setting the parameters ineach request notification repAA.

In contrast to setting for each M-ACTION request, FIG. 6 shows thenotification flow between the manager and the agent forparameter-dependent control of alarm realignment using a one-offparameter setting which is valid for a plurality of subsequent requestnotifications repAA. This advantageously achieves parameterization forthe alarm realignment without requiring the parameters to be reset eachtime. For this purpose, a notification M-SET is given precedence overthe request notifications repAA based on M-ACTION request (only one ofwhich is shown by way of illustration), said notification M-SET beingused to set the parameter or parameters relEN, relPS, priSV, relTI,priDT, which are inserted by the manager, in the agent as selectioncriteria for the alarms which are to be transmitted.

FIG. 7 shows the notification flow associated with the procedure shownin FIG. 6 when the two parameters priSV, relTI already described inrelation to FIG. 5 are set. In contrast to FIG. 5, the time intervaldefined by the start instant inst and the end instant inen, in the formof parameter value relTI—the agent is intended to register alarms andprioritize them according to urgency only in this time window—, and theurgency, in the form of parameter value priSV, are inserted into thesetting notification M-SET by the manager and sent to the agent inadvance. The settings remain valid for all successive requestnotifications until a new setting notification M-SET overwrites theprevious parameters or declares them to be invalid. The notificationsalNO contain the same parameter values specified by way of example inFIG. 5 and described in accordance with the associated comments.

FIG. 8 shows the notification flow between the manager and the agent forpolling the parameter values which are used for the alarm realignmentand are set in the agent, as shown in FIG. 7, and which were transmittedto the agent with the setting notification which was sent in advance.For this purpose, the manager generates an M-GET request with theparameter values which are to be polled—in the example the parametervalues priSV, relTI—and sends them to the agent. In response, thepolling manager receives a notification M-GET response with the agent'scurrently valid settings for the predetermined parameter values. In thepresent example, the agent's acknowledgement in the notification M-GETresponse comprises the values priSV=TRUE and relTI (inst=12.01.9810:15:00, inen=12.01.98 11:15:00). This allows the manager to checkwhich current setting is present, in order possibly to make changes whenparticular alarms are requested later by successively producing andsending request notifications.

What is claimed is:
 1. A method for handling alarms in atelecommunication system using a management network which has aplurality of management levels, wherein alarm data for active alarms istransmitted for alarm realignment between an agent on one managementlevel and at least one manager on a next highest management level, themethod comprising the steps of: sending, from the at least one managerto the agent, at least one request notification for transmission of thealarm data; sending, from the agent to the at least one manager,correlation information for assigning a respective request to the atleast one request notification with the alarm data; and controlling, viathe at least one manager, the alarm realignment on the basis of at leastone parameter sent to the agent by the at least one manager.
 2. A methodfor handling alarms in a telecommunication system using a managementnetwork which has a plurality of management levels as claimed in claim1, wherein the at least one manager sends the at least one parameter tothe agent in the at least one request notification.
 3. A method forhandling alarms in a telecommunication system using a management networkwhich has a plurality of management levels as claimed in claim 1,wherein the at least one manager sends the at least one parameter to theagent in a setting notification which has the precedence over the atleast one request notification.
 4. A method for handling alarms in atelecommunication system using a management network which has aplurality of management levels as claimed in claim 1, the method furthercomprising the step of: providing, via the at least one manager, the atleast one parameter with a parameter value which requests from the agentalarms which originate from selected agent units.
 5. A method forhandling alarms in a telecommunication system using a management networkwhich has a plurality of management levels as claimed in claim 1, themethod further comprising the step of: providing, via the at least onemanager, the at least one parameter with a parameter value whichrequests from the agent alarms for which there is an assumed urgency. 6.A method for handling alarms in a telecommunication system using amanagement network which has a plurality of management levels as claimedin claim 5, the method further comprising the step of: providing, viathe at least one manager, an additional parameter value which is used bythe agent to prioritize the requested alarms according to theirrespective urgencies.
 7. A method for handling alarms in atelecommunication system using a management network which has aplurality of management levels as claimed in claim 6, the method furthercomprising the step of: prioritizing, via the agent, the alarms whichare to be transmitted to the at least one manager according to differenturgency values.
 8. A method for handling alarms in a telecommunicationsystem using a management network which has a plurality of managementlevels as claimed in claim 1, the method further comprising the step of:providing, via the at least one manager, the at least one parameter witha parameter value which requests from the agent alarms which originatewithin a time interval which is defined by a start instant and an endinstant.
 9. A method for handling alarms in a telecommunication systemusing a management network which has a plurality of management levels asclaimed in claim 8, the method further comprising the step of:providing, via the at least one manager, an additional parameter valuewhich is used by the agent to prioritize the alarms according to anorigination instant of the alarms.
 10. A method for handling alarms in atelecommunication system using a management network which has aplurality of management levels as claimed in claim 9, the method furthercomprising the step of: providing and sending, via the agent, the alarmdata for the alarms having the earliest origination instants first; andproviding and sending, via the agent, the alarm data for the alarmshaving the most recent origination instants last.
 11. A method forhandling alarms in a telecommunication system using a management networkwhich has a plurality of management levels as claimed in claim 9, themethod further comprising the step of: providing and sending, via theagent, the alarm data for alarms having critical urgency first, forwhich a set of functions is assumed to be no longer present; andproviding and sending, via the agent, the alarm data for alarms havingnon-critical urgency last, for which a set of functions is assumed stillbe to present.
 12. A telecommunication system for handling alarms usinga management network which has a plurality of management levels, thealarm data for active alarms being transmitted for alarm realignmentbetween an agent on one management level and at least one manager on anext highest management level, the telecommunication system comprising:a transmission element in the element in the at least one manager forsending at least one request notification to the agent for transmissionof the alarm data; a receiving element in the at least one manager forreceiving correlation information from the agent for assigning arespective request tot he at least one request notification with thealarm data; and a control element in the at least one manager forcontrolling the alarm realignment on the basis of at least one parametersent to the agent by the at least one manager.
 13. A telecommunicationsystem for handling alarms using a management network which has aplurality of management levels as claimed in claim 12, wherein thecontrol element inserts the at least one parameter into the at least onerequest notification.
 14. A telecommunication system for handling alarmsusing a management network which has a plurality of management levels asclaimed in claim 12, wherein the control element inserts the at leastone parameter into a setting notification which has the precedence overthe at least one request notification and which is sent to the agent.15. A telecommunication system for handling alarms using a managementnetwork which has a plurality of management levels as claimed in claim12, wherein the at least one manager provides the at least one parameterwith a parameter value which requests from the agent alarms whichoriginate from selected agent units.
 16. A telecommunication system forhandling alarms using a management network which has a plurality ofmanagement levels as claimed in claim 12, wherein the at least onemanager provides the at least one parameter with a parameter value whichrequests from the agent alarms for which there is an assumed urgency.17. A telecommunication system for handling alarms using a managementnetwork which has a plurality of management levels as claimed in claim16, wherein the at least one manager provides an additional parametervalue which is used by the agent to prioritize the requested alarmsaccording to their respective urgencies.
 18. A telecommunication systemfor handling alarms using a management network which has a plurality ofmanagement levels as claimed in claim 12, wherein the at least onemanager provides the at least one parameter with a parameter value whichrequests from the agent alarms which originate within a time intervalwhich is defined by a start instant and an end instant.
 19. Atelecommunication system for handling alarms using a management networkwhich has a plurality of management levels as claimed in claim 18,wherein the at least one manager provides an additional parameter valuewhich is used by the agent to prioritize the alarms according to anorigination instant of the alarms.